Skip to main content

06 - 开源实现横评

前置：02 到 05 篇的机制。本篇把这些机制落到具体项目上。

本篇回答：这十四个项目分别是什么形态、要拖多少外部依赖、以及在你按印象去选之前，有哪四件事已经变了。

全部数据 gh api 实测于 2026-08-26，许可证逐个打开许可证文件读，依赖从 pyproject.toml / package.json 实读。

一、四个选型陷阱​

这三条不是"细节差异"，是按旧印象动手会直接白花几天的断点。

左边是模型和搜索结果里最常出现的说法，右边是 2026-08-25 实测「Zep 是开源的记忆服务端」docker compose 起 getzep/zep 就能自建该仓库只剩 Zep Cloud 的示例与集成，4,865★README 首句：This repository is not Zep's product or service。开源的是 getzep/graphiti「Letta 是 Python 的记忆服务端」pip install letta，记忆块存在数据库里letta-ai/letta 只剩落地页，V1 退役到 archive 分支当前源码 letta-ai/letta-code，TypeScript，3,116★，记忆是 git 仓库（05 篇第三节）「mem0 开源版自带图记忆」配置里加 graph_store 指向 Neo4j 即可MemoryConfig 里的 graph_store 字段在 2.0.0 被删v1.0.0 还有，v2.0.0 没有；图记忆的文档现在挂在 docs/platform 下
三条的共同点是"开源仓库变成了商业产品的入口"。判断一个记忆项目是不是真能自建，最快的办法是打开它的 pyproject.toml 或 package.json 看核心能力还在不在依赖里，而不是读 README 的功能列表。

第三条可以直接验证：

# v1.0.0 里有 graph_store
curl -s https://raw.githubusercontent.com/mem0ai/mem0/v1.0.0/mem0/configs/base.py | grep -n graph_store
#   47:    graph_store: GraphStoreConfig = Field(

# v2.0.0 里没有了
curl -s https://raw.githubusercontent.com/mem0ai/mem0/v2.0.0/mem0/configs/base.py | grep -n graph_store
#   （无输出）

主分支 MemoryConfig 现在的全部字段是：vector_store / llm / embedder / history_db_path / reranker / version / custom_instructions。仓库里的 examples/graph-db-demo/ 还留着 Neo4j、Memgraph、Kuzu、Neptune 四个 notebook，但它们对应的已经不是当前开源包的能力。

1.1 第四条：阿里的 MemoryScope 改名迁仓了​

modelscope/MemoryScope 现在 301 跳转到 agentscope-ai/ReMe，PyPI 包名也从 memoryscope 换成了 reme-ai（0.4.1.7）。旧仓库名在新 README 里被保留成一个历史分支 memoryscope_branch。

跳转是通的，所以这条不会让代码立刻挂掉 —— 它坑在搜索结果和二手资料：按 MemoryScope 搜到的教程，讲的是一个此后又改过两轮设计的版本。

二、十四个项目的基础事实​

项目★许可证（实读）语言最新版本最近提交
mem0ai/mem064,075Apache-2.0Pythonmem0ai 2.0.19（2026-08-24）2026-08-25
getzep/graphiti30,319Apache-2.0Pythongraphiti-core 0.29.3（2026-07-27）2026-08-21
topoteretes/cognee30,268Apache-2.0Pythoncognee 1.5.3（2026-08-23）2026-08-26
supermemoryai/supermemory29,074MITTypeScript—2026-08-26
TencentCloud/TencentDB-Agent-Memory24,556MIT（gh 判 NOASSERTION）TypeScript—2026-08-26
memvid/memvid16,448Apache-2.0Rust—2026-07-14
MemoriLabs/Memori16,224Apache-2.0（gh 判 NOASSERTION）Pythonmemorisdk 3.2.8（2026-04-13）2026-08-21
NevaMind-AI/memU14,347Apache-2.0（文件名是 LICENSE.txt）Python—2026-08-26
EverMind-AI/EverOS12,438Apache-2.0Python—2026-08-26
MemTensor/MemOS10,996Apache-2.0TypeScript—2026-08-26
plastic-labs/honcho6,844AGPL-3.0Pythonhoncho-ai 2.3.0（2026-08-11）2026-08-25
agentscope-ai/ReMe3,354Apache-2.0Pythonreme-ai 0.4.1.7（2026-08-13）2026-08-26
letta-ai/letta-code3,122Apache-2.0TypeScript—2026-08-26
langchain-ai/langmem1,626MITPythonlangmem 0.0.30（2025-10-27）2026-08-11

另外两个经常被列进候选、但值得先看一眼时间的：

项目★最近提交说明
memodb-io/memobase2,8582026-01-11用户画像式记忆（Profile 形态）。已停更七个多月
BAI-LAB/MemoryOS1,5602026-07-07EMNLP 2025 Oral 的配套实现，学术出身，工程完备度低于上表

2.1 许可证：一行需要过法务​

十四个里十三个是 Apache-2.0 或 MIT，只有 plastic-labs/honcho 是 AGPL-3.0。

AGPL 的传染性触发条件和 GPL 不同：通过网络把它作为服务提供给用户，就构成"分发"，要求提供完整对应源码。记忆层恰恰几乎总是以服务形态部署 —— 这不是理论风险。honcho 是这批里建仓最早的（2023-09-10），成熟度不低，但选它之前必须先过法务，不能按"反正是开源的"处理。

另外两行 gh 判不出许可证的（腾讯、Memori）是虚惊：许可证文件开头各自加了一段自己的声明，正文分别是标准 MIT 和 Apache-2.0，实读即可确认。

2.2 停更与错位​

LangMem 那一行的错位要注意：仓库还在提交（2026-08-11），但 PyPI 最新版停在 2025-10-27 的 0.0.30，也就是十个月没发版，且始终没走出 0.0.x。它作为 LangGraph 生态里的记忆原语可用，但不适合当成独立的记忆基础设施依赖。

三、部署重量：要拖多少外部服务​

这是横评里最有决策价值的一维 —— 它决定了 POC 阶段你要花半天还是三天。

从左到右起步成本递增；能力不严格递增 —— 第一档已经能满足相当一部分需求零外部服务cognee（默认配置）Anthropic memory 工具memU · ReMe · EverOSSQLite ＋ 嵌入式向量与图或者干脆就是文件＋ 一个向量库mem0（默认 Qdrant）LangMem ＋ Postgres Storesupermemory · honcho（Postgres）mem0 支持 26 种向量后端已有 pgvector 就不必新增组件＋ 图数据库graphiti（硬依赖 neo4j 驱动）可换 FalkorDB / NeptuneMemOSKuzu 那条路已标记废弃上游项目无人维护＋ 一整套服务腾讯 TencentDBAgent Memory四个服务 ＋ 数据库换来的是团队级共享与三级权限另有一类不在这条轴上：Zep Cloud、mem0 的图记忆、Letta Cloud —— 它们的开源仓库只是入口，完整实现只能托管。graphiti 的 pyproject.toml 把 neo4j>=5.26.0 放在必选依赖里，不是 extra —— 即使你打算用 FalkorDB，这个包也会被装上。
第一档的存在感常被低估：cognee 默认配置是 SQLite ＋ LanceDB ＋ 内嵌 Kuzu，pip install 之后直接能跑；ReMe 和 EverOS 更彻底 —— 记忆就是一堆本地 Markdown。第四档的成本高一个量级，但它买到的是别的档次给不了的东西：多个 Agent、多个用户共用同一份经验，且能按团队和角色控制谁看得到什么。

3.1 存储依赖实读​

项目必选依赖可选后端
mem0qdrant-client、sqlalchemy（history 表）、一个 LLM、一个嵌入模型26 个向量后端：pgvector、Milvus、Elasticsearch、Redis、Valkey、OpenSearch、Weaviate、Chroma、FAISS、MongoDB、Cassandra、S3 Vectors 等
graphitineo4j>=5.26.0（写死在主依赖里）、openaiFalkorDB、Neptune、falkordblite（Python ≥3.12 的嵌入式方案）；Kuzu 那条 extra 已注明上游无人维护、将被移除
cogneesqlalchemy＋aiosqlite、lancedb、内嵌 kuzu、litellm、fastapiNeo4j、Neptune、Postgres、Turso
LangMemLangGraph 的 BaseStoreInMemoryStore（重启即丢）、AsyncPostgresStore（生产）
letta-codegit ＋ 一个 memFS 服务端默认指向 api.letta.com，可用 LETTA_MEMFS_BASE_URL 换成自建
TencentDB Agent Memory四个服务（MemoryCore / MemoryKnowledge / MemoryPanel / MemoryProxy）＋ 数据库仓库带 deploy/ 与 Docker 编排，可整套自建
ReMe无外部服务，记忆就是本地 Markdown需要时接向量后端
honchoPostgres—（注意许可证，见 2.1）

LangMem 的 InMemoryStore 那一行是踩坑高发处：官方 README 的快速开始用的就是它，重启进程记忆全丢。上生产必须换成 AsyncPostgresStore。

四、能力矩阵​

能力mem0graphiticognee腾讯ReMeletta-codememory 工具
抽取式写入✅✅✅✅ 异步分层✅模型自管模型自管
双时间轴（03 篇）❌✅ 四字段部分❌❌❌❌
作废而非删除❌ 纯追加✅ 边失效部分分层覆盖文件改写git 历史❌
图 / 多跳检索仅托管版✅✅✅ CodeGraph❌❌❌
混合检索（向量＋BM25）有 reranker 模块✅ 三路 ＋ 五种重排✅✅ BM25＋向量＋RRF向量为主❌❌
多租户过滤✅ 三维 filters✅ group_id 分区✅✅ 团队/用户/Agent 三级 ACL目录隔离一 agent 一仓库目录隔离
强制注入某条自己实现自己实现自己实现固定绑定自己实现❌❌
版本 / 回滚history 表靠时间字段回溯❌❌❌✅ git❌
人可直接读改❌❌❌有管理面板✅ Markdown✅✅

两处需要说明：

  • graphiti 的 group_id 是图分区字段，写在 Edge 基类上（group_id: str = Field(description='partition of the graph')）。它是必填的，比 mem0 那种"漏传就退化成全库检索"的可选 filter 结构上更安全
  • "强制注入"这一行只有腾讯那一列有现成机制。它把 Chat Memory、Skill、Wiki、CodeGraph 统一注册成"记忆资产"，再用固定绑定把某个资产钉死在某个 Agent 上 —— 这正是 04 篇第四节说的"安全类记忆绕过排序直接注入"。其余各列都得在应用层自己加一次按 user_id 的精确查询
  • 腾讯那一列的分层是这批里独一份：对话先存 L0 原文，异步管线再提炼成 L1 事实、L2 场景块、L3 长期画像；取的时候先用 L2/L3 快速铺上下文，需要具体事实才回落到 L1/L0，并且用条数、字符预算、超时三重上限挡住"记忆撑爆上下文"。这套结构对应本专题 02 到 04 篇的三步，是目前公开实现里做得最完整的一个

五、判断一个记忆项目还活着的四个信号​

star 数在这个领域尤其不可靠 —— 上表里 star 最少的两个（letta-code 3,122、LangMem 1,626）一个是活跃主力，一个近乎停滞。四个更可靠的信号：

信号怎么看为什么可靠
发版节奏，不是提交节奏PyPI / npm 上最新版本的发布日期仓库有提交但十个月不发版，说明它不是被当成给外部用的库在维护（LangMem）
核心能力在不在依赖里打开 pyproject.toml / package.jsonREADME 的功能列表可能描述的是托管版（mem0 的图记忆）
有没有从主仓库搬走看 README 首段和默认分支的文件列表；对着旧地址 curl -I 看有没有 301只剩落地页或示例的仓库，star 数还挂在那儿（zep、letta）；也有单纯改名的（MemoryScope → ReMe），跳转虽通但二手资料全是旧的
废弃标记依赖注释、extra 的说明文字graphiti 在 Kuzu extra 上直接写了上游无人维护、将被移除 —— 比任何第三方评测都准

六、五条选型路径​

先回答左边那一列，右边就定了 —— 不要从"哪个 star 多"开始单用户 · 长任务 · 记忆条目几十条排查成本最重要，不需要强制注入文件式：memory 工具自己实现，或 letta-code代价：每次读写一个模型轮次；收益：cat 一下就知道它记了什么多用户 · 事实扁平 · 已有向量库用户偏好、禁忌、常用配置这一类mem0 ＋ 你已有的 pgvector 或 Milvus不新增组件；注意图记忆不在开源版里，需要图就别选它事实会变 · 要回溯 · 要多跳「用户当时的负责人是谁」这类问题graphiti ＋ Neo4j 或 FalkorDB代价：多一个图数据库，写入多一次冲突判定调用多个 Agent 要共享同一份经验还要按团队和角色控制谁看得到��什么腾讯 TencentDB Agent Memory代价：四个服务要部署；收益：三级 ACL 与固定绑定是现成的只想先验证记忆有没有用还没到定架构的阶段cognee 默认配置，或 mem0 ＋ 本地 Qdrant半天能跑通；先拿到"有没有用"的结论，再讨论换不换
第二条和第三条的分界就是 03 篇那张双时间轴图：如果你的记忆里没有"会失效的事实"，图方案带来的那套时间字段是纯成本。第四条是另一个维度上的分岔 —— 前三条都在问"记什么、怎么取"，只有它在问"这份记忆归谁"，而这个问题一旦出现，前三条的方案都要在应用层自己补一套权限。

换实现的成本要提前算。这一层没有任何跨实现的语义约定 —— 不像可观测性那一层至少有 gen_ai.* 和 OpenInference 两套规范可以对齐。mem0 的一条记忆是带 hash 和 metadata 的文本，graphiti 的一条记忆是带四个时间字段的图边，腾讯那套是分了四层的资产，两两之间都没有无损转换。把"以后换得掉"当成假设是危险的 —— 更现实的做法是在应用和记忆库之间自己留一层薄接口，只暴露 remember(...) / recall(...) 两个方法，把具体实现挡在后面。

七、小结​

  • 四个断点：Zep 的开源服务端已不存在、Letta 换了仓库换了语言、mem0 的图记忆在 2.0.0 从开源包里删了、阿里的 MemoryScope 改名迁成了 ReMe
  • 判断项目活跃度看发版日期和依赖列表，不看 star —— 这个领域 star 与实际维护状态严重脱钩
  • 部署重量分四档，第一档（零外部服务）能覆盖的场景比通常以为的多；第四档（腾讯那套四个服务）买到的是团队级共享与三级权限，是别的档次给不了的
  • 许可证只有 plastic-labs/honcho 是 AGPL-3.0，而记忆层几乎总以服务形态部署，选它之前必须过法务
  • "强制注入安全类记忆"只有腾讯那套有现成机制（资产固定绑定），其余都要在应用层自己加
  • 没有跨实现的数据格式，自己留一层薄接口是唯一现实的解耦手段

下一篇：07 - 失败模式、评测与选型，记忆怎么被污染、榜单数字为什么互相打架，以及一套落地顺序。

← 回到 专题索引